|
ITN584 - longmuir |
|
|
SYSTEM DESIGN PROJECT
Two Remote Access Models For The Company
SYSTEM DESIGN PROJECT
Two Remote Access Models For The Company
SYSTEM DESIGN PROJECT: To design and implement a remote access control system for: Authorised company staff to access a reduced set of resources on their staff network (or Intranet), from insecure networked locations.
The company has a local area network on which resides company and client sensitive documentation, which it has developed as in-house procedures or as consultancy services for clients. Other non-sensitive documentation also exists within the company network that could be considered low-risk material, but when stored collectively on the central fileserver is considered a much higher risk. The degree of harm that non-authorised discloses of such material could in cases led to a lack of confidence in the company and/or it's clients.
The company also provides secure connections to the Internet and secure Internet server hosting for clients. Access control restrictions are already in place to protect these resources. The sensitive documents mentioned previously contain details of the operational and implemented access controls for these services: such as access, security, contingency and intrusion polices and procedures.
All company staff have access to the staff network (or Intranet).
The legal ramifications from unauthorised access, disclosure, loss, compromise, or misuse of sensitive documents, servers, or connections is always being reassessed with any new service implementation.
An analysis of the current in place access controls will give a basis for access controls that will be required for the solution. These controls are a reflection of the Company’s security policies.
The company has separated its network into two. These two networks are logically connected via firewall infrastructures. One network contains the Network Operations Centre (NOC) and the other is effectively the staff network (or Intranet).
The separation of the networks reflects the company’s security policy which outlines the separation of a secure support environment known as the NOC and the general staff network (or Intranet). The NOC provides the management and monitoring functions of the firewall infrastructure. The connections between these networks are restricted by allowing only services requested from the NOC to access the staff network, while staff network users can not access resources located within the NOC.
Access to the NOC requires physical access to terminals and consoles within the NOC. This access is controlled both at a physical level (swipe card access to rooms) and at a logical level (authorised userid/password logins). Access controls for the NOC are only briefly detailed within this document, as they are considered too sensitive to publish.
Access to resources on the staff network is controlled by discretionary access controls. These controls are implemented based on userid and groupid of which an individual has been assigned to on Unix and NT platforms. This allows access to be assigned by the resource (file) owners and the system administrators.
Currently a staff member has to be physically onsite to access the staff network. Out of hours access to the staff network can be described by the entry sequence: a) deadlock key to the premises (something you have), b) a building alarm code PIN (something you know), and c) a swipe card plus user PIN (something you have plus something you know). The swipe card system in place is implemented with a hierarchy of privileges.
As a point of interest, physical access to the NOC requires the above sequence; in addition, other mechanisms based on a hierarchical access matrix. In either case normal hours access removes steps a) and b) but replaces them with visual staff recognition (something you are).
While the swipe card hierarchical access matrix is a role based access control mechanism, all staff have access to workstations on the staff network.
The logical protection of the company's staff network is setup with a series of firewalls and can be likened to a diode in it's current configuration of only allowing internally initiated services (such as HTTP and FTP) to the Internet. An exception is e-mail (SMTP) which has restricted bi-directional access between the internal server and an external relay server.
The company currently has a simplified content filtering mechanism in place for non-encrypted traffic. This is implemented as payload inspection of in and out bound SMTP traffic for viruses and trojans. A framework exists to do content filtering on active web content and unauthorised or inappropriate usage if future associated risks enforce this as a requirement.
A restricted set of incoming resource requests from the NOC is also allowed to access the staff network (the NOC is considered a more secure network than the staff network).
Having now reviewed the current access controls in place by the Company. Access controls for the remote access solution have to be derived. These requirements are based on the current access procedures in place along with an additional Company requirement. A restriction on permitting additional ‘unknown’ services without an independent review. Also to be factored-in is future growth of the Company and staff numbers using the access solution.
The access controls that are to be applied to any remote access solution will parallel the current physical access controls and add complementary logical network access controls based on that have been established and in use in the staff network.
The access control system to be put into place should be based on granting access to authorised entities. It should ensure confidentiality, integrity and system availability. It should also reflect the company’s security policy.
The access mechanism must separately authenticate and identify every user. Current physical access control systems in place are based on a) something you have and b) something you know. This implies that similar logical procedures should be put in place.
The access mechanism must ensure that specified data only is manipulated by a restricted set of access methods. Since the staff network is maintained using discretionary access controls on the Unix and Windows NT platforms, the implemented solution should also obey those rules. The implemented solution should not be able to increase user privileges beyond that which the user would have on the staff network.
The transfer of viruses and trojans into the company’s staff network will have to be addressed along with possible future content filtering policies the company may apply.
The access mechanism must maintain an auditing log of accesses. Monitoring access will lead to improvements in access procedures based upon analysis of legitimate operational access (or user behaviour) to the system. Detection of ‘exploratory’ and system attack scenarios from the logs should also be possible. This is a double-edged sword: too much logging and nobody will inspect the log; too little and system-compromising events could go unnoticed.
The access mechanism must be protected against tampering and unauthorised change. Procedures must be put in place for the management of each of the components used in the implemented solution. This includes the authentication and authorisation mechanisms put into place.
The access mechanism must ensure that the system works promptly and services are not denied to authorised users. The implemented solution should be attendant to access at all times and a procedure should be designed to inform authorised users of any maintenance outages. If possible denial of service attacks should be minimised.
Ensure that confidentiality of company sensitive documentation and the current user session via the access mechanism. Interception of information that is transmitted is protected against via network transport encryption.
The aim of this project is to document and provide an implementation framework of two controlled access mechanisms through the current logical infrastructure to provide remote access to the staff network, from insecure networked locations.
Two different solution models were looked at:
· a generic and simple access mechanism with a very restricted set of resource accesses. Which makes use of the current network infrastructure; and
· an extended access mechanism, where control of both end-points exists. This introduces a new Transport application into the current infrastructure. The client end-point device will be considered an extension of the staff network. Under the Company guidelines an independent review is required for any new ‘unknown’ services.
Only the first is to be detailed, the second introduces such complexity to the researcher that greater time than that available is required to understand and develop the access mechanism further.
The simple access mechanism should be as generic as possible to cope with usage from unknown and possible restricted access networks. It is assumed that Secure Sockets Later (SSL) based HTTP services to the Internet will be available. Staff located on client premises (or networks) may only have access to the client's installed application base and not be able to install additional software. These systems may also lack removable media devices such as a floppy diskette drive, or CD-ROMs.
A web server using SSL encrypted HTTP will be located within the staff network. Access to the web server from the greater Internet will be via a proxy service on the outlying firewall. Both the web server and the proxy will provide authentication services.
The SSL protocol, originally developed by Netscape is inserted into the ISO network stack between the Transport layer and the Application layer, in a role similar to the Presentation and Session layers. In our case, TCP is the Transport layer and HTTP is the Application layer. A SSL server certificate will be generated for each HTTP server configured, it will also be signed by a Certification Authority (CA) that is well known.
This web server will provide HTTP access to the restricted services provided by the Microsoft Outlook web interface on Microsoft’s Internet information server. This service will be available for authorised staff usage from anywhere that has the assumed basic SSL based HTTP access to the Internet, and the user has no possible means of providing additional something you have authentication.
An additional service of telnet access to the staff network can also be provided via embedded VBScript within active server pages on an additional Microsoft Internet information server. Dart Communications PowerTCP Telnet Tool will be used to provide this functionality. This service will be available for authorised staff usage from anywhere that has the assumed basic SSL based HTTP access to the Internet, and the user has some possible means of providing additional something you have authentication. This will be in the form of pre-generated one time password or a hardware token.
Two locations within the proposed simple access mechanism provide points that user authentication and authorisation can be applied: they are at the web server connection end and at the proxying (or relaying) outlying firewall. Users of the simple access mechanism will be authenticated at both locations.
Authentication at the web servers located within the staff network will have the same user identification methods deployed as on other systems in the staff network. Currently basic userid/password control (something you know). This gives the staff network administrators the flexibility to synchronise staff network access procedures with that of the web server.
Client based authentication
using SSL (something you have) is not
considered here, but could be implemented on the web servers as an additional
identification method. While convenient it is not recommended that these client
based digital signatures replace the basic userid/password access control.
Ignoring some staff privacy issues that could arise: the following negatives
should be considered. The costs involved in purchasing individual personal
certificates or the overhead of producing and maintaining an in-house CA. The
mapping of certificates to local web server access userids requires extra
administrative support on the web server. The remote client may not have any
way for the user to install their personal certificate: possibly the case of no
removal media device. Lastly, some web browsers do not support pass-phrase
access to the certificate, allowing anybody that has access to the workstation,
access to the certificate.
Authentication at the outlying firewall is only achievable if it is configured as a relaying proxy. This must be the case since the internal staff network web server addresses must have network address translation applied to them.
The firewall accepts the incoming web server addressed traffic to one of its interfaces, it checks if this is allowed at the Transport layer (TCP) via its configuration (or rule set). The interface will be implemented as a virtual interface to allow multiple web server mappings. This will be required if the additional telnet web service is also provided to staff. The firewall also acts as a point of authentication and authorisation for each of these services. Rather than create and maintain the authentication and authorisation lists on the firewall device, the firewall will communicate with a central RADIUS server.
RADIUS is a standard for centralising the authentication, authorisation and accounting of remote access users. RADIUS allows servers to authenticate remote users and authorise their access to the requested system or service. This allows the company to maintain it’s remote access user profiles in a central database that all remote access servers can share. This gives flexibility to add additional remote access solutions using the one central user access database at a single administered network point.
RADIUS is supported by at least a dozen firewall vendors. All firewalls used by the company support RADIUS. RADIUS supports many forms of authentication, from basic userid/password support, one time password’s (such as s/key), to software and hardware based token systems.
While a hardware based token system is considered the best solution for these remote access users, the costs of such system could be considered prohibiting. Such token systems could be retro fitted into the RADIUS system in the future with out requiring major system redesign. Recondmendations are 1) the calculator based challenge-response Secure Computing’s Safeword token authentication system that has RADIUS support via proxy RADIUS; and 2) the clock based RSA’s ACE/Server securID token authentication system which has native radius support. Hardware token systems work on the principle of something you know plus something you have.
Given that hardware tokens are not going to be used initially and software token systems (like Kerberos) require modified client software, s/key will be the preferred option for remote user authentication.
While the s/key system is a software based one time password system, it provides a pseudo something you know plus something you have authentication system. S/key passwords can be stored as a printed out list which the user caries around; alternatively the user has access to an independent application which can be used to calculate the correct one time password given the sequence number. Either way, a shared secret is given but never transmitted.
Active Server Pages (ASP) is a technology developed by Microsoft. Web pages ASP can be developed in JavaScript, VBscript, or Perl and are integrated into the HTML of your web server pages. The code is compiled on the fly by the server and the resulting output is standard HTML. By using ASP, user access to resources on the staff network is limited to the privileges that these embedded programs have on the web server.
While privileges beyond those granted to the user are possible, such instances are limited to poorly configured web server implementation and system created bugs. The remote user is unable to increase their privileges beyond that which the web server has given them.
Since all data and file manipulation occurs on or via the web server interface, no documentation is transferred outside the staff network except for screen displays. Thus, current and future content filtering mechanisms will be not required to extend to this remote access solution. Of course, cutting and pasting can still be done, therefore staff discretion and integrity must be relied upon.
Logs on the proxying firewall will contain information such as source IP address, the date and time, and authentication status. If the session is permitted the duration, and transfer byte count should also be available.
The RADIUS server logs will contain detail of the authentication method for the user, the remote device requesting the authentication, the time and date along with the authentication status that was returned to the device.
The web server logs will not be able to detail much beyond basic information about resource access functions (such as show message x, delete message y, and telnet to host z). HTTP is a stateless protocol. User functions will either be described as part of a URL or via cookie requests from the server of the client. Greater detail of user resource manipulation will be found via the Microsoft Exchange server access logs or on the remote servers that were connected to via telnet. Consideration should be given to auditing these logs as well.
Since the access logs are stored in several locations, manual procedures will need to be put into place to collate and review the logs. The usage of all these logs will provide an historical record of events, which would provide legal evidence of inquisitive or destructive behaviour of authorised or non-authorised identities. As such these logs should be archived together in an unmodified format on read-only media, by an individual that the Company has authorised.
Tampering and unauthorised change should be reduced by requiring the Company staff to apply formal change control procedures on any of the systems used to create this access control mechanism. Most daily management will be with the maintenance of the user authentication and authorisation lists, which are maintained on the RADIUS server. The web servers themselves should be managed in the same manner as other important servers on the staff network. Once the outlying proxing firewall is configured to provide these new access mechanisms, further change shouldn’t be necessary.
Obviously, with three major systems forming the minimal requirements of the simple access mechanism, a fault with any of the three will cause a complete service failure. System redundancy and duplication could alleviate this, but may require manual switch over depending on possible implementation.
Manual procedures should be put into place to ensure valid creation and removal of users in the RADIUS database. The firewall should also make use of known tricks to reduce denial of service attacks, this should be applied with reasonable limits to stop possible valid user denial.
The SSL protocol is being used to deliver server and (optional) client authentication, data encryption, and message integrity.
SSL enabled software uses standard public-key cryptography methods to check server or client digital certificates are valid and have been issued by a CA that it trusts. These CAs trusts are usually pre-installed as part of the web server or browser distributions.
SSL server authentication allows a user to confirm a server's identity. Optional SSL client authentication allows a server to confirm a user's identity.
An encrypted SSL connection requires all information sent between a client and a server to be encrypted by the sending software and decrypted by the receiving software, thus providing a high degree of session privacy. Public-key encryption techniques are used to generate shared secrets between the server and the client, which will be different with every use.
The use of digital hashing functions within the SSL data connection ensures that data sent over an encrypted SSL connection is protected against tampering. This provides a method, which the client software can use to determine whether the data has been altered in transit.
The following notes include some issues of the basic access mechanism that were found during system implementation.
Also included are some details (mostly random ideas) of the extended access mechanism. This was dropped as the complexity of the proposed solution increased. The more complex the access system becomes, the harder the security evaluation is. Time to research and further develop issues found (and yet to be found) would end up with a functional solution.
S/key support in RADIUS – The only RADIUS server that supported s/key found was Cisco’s CiscoSecure Access Control Server for Solaris (the NT version doesn’t support s/key). This product was found to be expensive as it also required a licensed version of Oracle or Sybase also on the system. The company will the purchase the Cisco product in the not too near future. Found several public and licensed RADIUS servers that supported Pluggible Authentication Modules (PAM), this allowed support for s/key on a FreeBSD platform.
Maintaining the integrity of the RADIUS server could be difficult – it’s easy to misconfigure. A GUI is to be introduced to provide change procedure syntax for common processes.
SSL certificate certification – needed to provide facsimile of ‘proof of right to use’ for the certificate’s Common Name (DNS name) field to CA.
The company decided that the telnet solution wasn’t suitable – not enough logging (wanted full season logging at the client) – not many resources on the staff network that would require remote telnet access.
Noted problems with Dart Communications PowerTCP Telnet Tool VBScript integration into ASP. They’re not really supporting ASP yet.
“Security’s worst enemy is complexity.” Unknown.
The extended access mechanism is to be deployed where control of both the client and server systems exist. The client system must be trustworthy.
A trustworthy system consists of computer hardware, software, and procedures that are reasonably secure from intrusion and misuse. It should provide a reasonable level of availability and functionality. Suited to its intended resource functions, and adheres to the company’s accepted security practices.
The company must create new policies and procedures which detail usage of such end-point systems. For example in a home situation, the unauthorised access of the remote workstation client software by family members whom may have permission to use that equipment but not the company’s resources.
The user must manually provide measures to protect transferred files on client or any. How? Encryption? What about storage on removable media? The transfer of viruses and Trojan’s into the company’s computing system. There should be company applied rules. The client solution should have anti-virus software.
What about the interception of information whilst it is being processed on a multi-user access platform. Will there be sandboxes like with java applets? The user should do all that is reasonable to restriction access to client workstation and hence the reduce risk.
It is expected that this extended access mechanism will be restricted to company owned portable workstations used by staff when required by work duties to be away from a staff office for long periods.
Implementation by L2TP (encapsulation of PPP over IP). Control must exist of both the client and server end points.
Why L2TP? It offers access for mobile users, telecommuters, and small offices through dialin services such as PSTN, and ISDN; can also be used over Frame-Relay and ATM circuits. Supports ISO layer 3 protocols such as IP, IPX and Appletalk. L2TP supports dynamic address allocation and PPP dial-back. Tunnel via connections to any local ISP with L2TP support.
Authentication is by PPP methods such as RADIUS. Link level encryption by PPP’s Encryption Control Protocol (ECP) using DES.
Public domain implementations of L2TP can be found for linux and Solaris. Cisco and Cabletron are providing support L2TP within their routers.
L2TP uses UDP port 1701 – not a standard service – application based firewalls prefer TCP based services: otherwise they are just smart routers.
Why use IPSec with L2TP? Because PPP’s ECP only meets confidentiality requirements and doesn’t address integity (no digital hashing function to check if data has been modified).
Both L2TP and IPSec are still in standards development.
IPSec provides two choices of security service: Authentication Header (AH), which essentially allows authentication of the sender of data, and the Encapsulating Security Payload (ESP), which supports both authentication of the sender and encryption of data as well. Session keys are exchanged via Internet Key Exchange (IKE).
IPSec AH and ESP are layer 3 protocols and IKE uses UDP port 500 – these are currently non standard services and will have to be reviewed as stated in the company’s policies.
The shared secret key(s) are stored as x.509 certificates on smart cards. A smart card and acceptor (or smart card reader) must be at each end point of the tunnel. The smart card must have enough cyclic filesystem space to store and manage multiple keys on the server end point – this will be an issue.
The acceptor will be connected via a system hardware slot (such as a PCI slot on an ATX motherboard) within the trusted system at each end point. All access from the system application to the acceptor must be via the ISO 7816-4 (commands for interchange) application protocol data units (APDU) command set.
The smart cards require a user PIN to access the stored certificate. An access control matrix, would also provide privileged user access other parts of the card filesystem, and should ensure against invalid access control conditions.
What about a lost smart card (and secret key)?
Address Allocation for Private Internets – RFC 1918
http://www.ietf.org/rfc/rfc1918.txt
ISO layers
http://www.itu.int/itudoc/itu-t/rec/x/x200-499/x200.html
Dart Communications PowerTCP Telnet Tool
http://dart.com/powertcp/default.asp?tool=telnet
Microsoft Internet information server
http://www.microsoft.com/windows2000/guide/server/features/web.asp
RADIUS
http://www.ietf.org/rfc/rfc2058.txt
SSL
http://www.netscape.com/eng/ssl3/
Secure Computing’s (formerly known as Enigma Logic) Safeword
http://www.securecomputing.com/
RSA’s (formerly known as Security Dynamics Inc.) ACE/Server securID
http://www.rsasecurity.com/products/securid/
S/key
http://www.ieft.org/rfc/rfc1760.txt
L2TP
http://www.ietf.org/html.charters/l2tpext-charter.html
http://www.marko.net/l2tp/
IPSec
http://www.ietf.org/html.charters/ipsec-charter.html
Securing L2TP using IPSec
http://www.ietf.org/internet-drafts/draft-ietf-pppext-l2tp-security-05.txt